1.1. Time Sharing Systems
In most large computing systems a timesharing computing environment is implemented. As illustrated in FIG. 1c, such a system may include "resources" such as one or more central processing units (CPUs) 2 configured to share components such as main memory 3, disk or tape storage 4, and a printer 6. The system may also include user terminals such as workstations WA and WB, which in many implementations may have their own local resources such as one or more CPU's and associated main memory (not shown) as well as perhaps a printer 7 and disk storage 8. The CPU(s) 2 execute program sequences that cause the CPUs to process commands and requests transmitted by users from the workstations WA and WB in accordance with known timesharing methods.
In such an environment, the system resources are centrally managed by a trusted authority. Because the central authority controls all access to the system resources, it is often fully trusted. In other words, the central authority is designed and maintained to ensure that the security plan for the timesharing system is properly implemented. In such timesharing environments, when a "principal" on the system (e.g., a user) requests access to a system "resource" (e.g., a printer or file server) the central trusted authority determines whether the principal possesses the necessary security attributes to access the resource. If so, the trusted authority allows the access.
In these timesharing computer systems and the like, almost all access control is handled by the central trusted authority. As such, the trustworthiness of the central authority must be maintained. Because of the importance in having a trusted central authority, many prior art devices have emphasized the importance of having a single, trusted controlling authority.
1.2 Distributed Systems
In contrast to timesharing environments, there also exist "distributed systems." In distributed systems several separate computer systems are linked together in a network to share various system resources. In such systems, there is generally no single trusted central manager that can implement the security policy for the system. As such, each system resource on the network is often required to implement its own security policy.
In such distributed systems a user typically requests access to a particular system resource. That system resource is then itself responsible for determining the access rights of the requester and allowing or rejecting the requested access.
The need for each resource to enforce its own security policy often results in complexities not encountered in timesharing environments. For example, each principal (e.g., user) on a distributed system is often assigned a user name. Access to the system resources is often on the basis of the particular access rights associated with a particular user and his name.
In theory, each system resource could include a listing of all of the principals and their access rights and user names. However, such a situation is often impractical as it would require additional memory and maintenance for each resource. Further, if numerous system resources exist, the addition (or deletion) or one principal's would require the modification of numerous lists.
One alternative utilized in the prior art is to have a central list accessible to all resources on the network. Because of the need for all system resources to have access to all of the principals and their names, a list of the principals and their names is often stored in a "global naming service" (GNS). A global naming service is a system resource which contains a list of all of the principals authorized to use the system and their names. Unlike a timesharing environment where the naming service is centrally controlled, in a distributed environment, the naming service is merely one of many system resources.
In most security systems, access to a system resource is determined on the basis of group memberships. Thus, the security policy of a particular resource may dictate that members of only a certain number of selected groups have access to that resource. Because the principal requests access to the resource, the resource must determine whether the requester is a member of one of the selected groups. If so, access is allowed. If not, access is denied.
Because it may be desirable for groups to contain other groups (or subgroups) the verification of a particular principal as a member of a large structured group can often be extremely slow.
1.3. Security Needs for a Distributed System
As discussed above, security systems for distributed networks often encounter complexities not found in centralized networks. For example, any system attempting to provide security for a distributed network must have the ability for a user to authorize a computer to operate on user's behalf and only to do so while authorized. Further such a system should have the ability for an authorized computer to present authorization to other computers in a secure and verifiable manner; and the ability for the user to rescind the authorization.
Because distributed systems generally have several workstations, it is desirable to allow a user to access the system resources regardless of which workstation he is logged into. However, because all systems on the network cannot be equally trusted, it may be desirable to prevent a user from accessing certain information on certain untrusted workstations.
Second, because distributed networks often have a large number of network entities, it is generally desirable to organize the entities into manageable groups. To implement a security policy properly, it is desirable to be able to manage these groups through an effective security policy.